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ABSTRACT 


The Naval Air systems Command (NAVAIR) is seeking to 
improve its information resource management (IRM) through the 
i3e of information systems (IS) architectures. Although 
several attempts have been made, NAVAIR currently has no 
overall IS plan. Enterprise Architecture Planning (EAP) is a 
comprehensive planning methodology that allows organizations 
to rapidly adapt and survive in dynamic environments. The use 
of EAP and the tools and resources currently available will 
provide NAVAIR with a strategic advantage in an era of 
diminishing resources. This thesis presents NAVAIR with an 
analysis of methodologies and tools which will prove useful in 
the development of an overall information systems 
architecture. 
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I. INTRODUCTION 


A. PROBLEM STATEMENT 

The Department of Defense has received much criticism in 
recent years for the mismanagement of its information 
resources and automated data processing. Previous practices 
in the management of information systems have been quite 
costly. Business methods have been developed on an ad hoc 
basis resulting in numerous redundant computer systems. 
Minimal standardization of data across the DOD has reduced 
portability and integration capabilities of current 
applications. The Department has now shifted towards viewing 
information as a valuable resource, attempting to accurately 
document and plan information systems, thereby insuring more 
cost effective, integrated systems are developed. 

The Naval Air Systems Command (NAVAIR) is seeking to 
improve its information resource management (IRM) through the 
use of information systems (IS) architecture. Although 
several previous attempts have been made, NAVAIR currently has 
no overall IS plan. Without an IS architecture they must make 
reductions in resources and programs with little grasp of what 
aspects of their organization are critical to its success. It 
is essential for NAVAIR to have an IS architecture to ensure 
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budget decisions are made from the most informed posture 
possible and that their reduced resources are managed 
effectively. 

B. BACKGROUND 

In October of 1989, the Department of Defense established 

the Corporate Information Management (CIM) initiative in 

response to a Defense Management Report (DMR) condemning DOD 

IRM business practices. CIM has been implemented in the 

private sector and was chosen based on its ability to overcome 

problems similar to those which have plagued the DOD: 

including management structures, staffing levels, and 
entrenched corporate policies and cultures that impeded 
decisionmaking, frustrated innovation, obscured 
accountability for success and failure, and imposed 
excessive overhead costs. [Ref. 1: p. 15] 

The objective of CIM is to "increase the effectiveness of 

information management while reducing the costs of information 

management to the Department." [Ref. 2: p. 6] CIM emphasizes 

interoperability and consistency between DOD components 

through the use of an open architecture, common data 

definition, and standardization of information resources, all 

of which facilitates the sharing of information. 

The Department of Defense identified eight administrative 
functional areas which have common information requirements 
within each service. Consolidation of related functions and 
the elimination of unnecessary management layers within these 
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areas will increase their efficiency while lowering overall 
costs. [Ref. 1: p. 16] The eight functional areas are: 

• Civilian Payroll 

• Human Resources 

• Contract Payment 

• Distribution Center (or Warehousing) 

• Material Management 

• Financial Operations 

• Medical 

• Government Furnished Materials [Ref. 3: p, 3] 

A Functional Group is assigned to each area and is tasked with 
developing an IS strategy that is both unified and 
standardized at the DOD level as opposed to the individual 
service or agency level. 

Designed as the vision of DOD in the year 2000, CIM is 
comprised of fourteen guiding principles. Several key 
principles are: 


• Information will be managed through centralized control 
and decentralized execution. 

• Proposed and existing business methods will be subject 
routinely to cost-benefit analysis which includes 
benchmarking against the best public and private sector 
achievement. 

• Information systems performing the same function must be 
common unless specific analysis determines they should be 
unique. 

• The computing and communications infrastructure will be 
transparent to the information systems that rely upon it. 
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• Common definitions and standards for data will exist DOD- 
wide. 

• Data will be entered only once. [Ref. 4: p. 3] 

These principles apply to all DOD components and must be 
incorporated in existing IRM plans and adapted to fit each 
particular mission. 

Interoperability between the armed forces is a major 
premise of CIM, as four different methods of resource 
management are merged into one. An even greater task lies 
within each service as no common IS plan exists. A division 
of labor has been established to prevent duplication of effort 
but the immense size of this initiative necessitates several 
years for completion of initial modules. 

The Department of Navy has significantly increased its 
attention on IRM efforts in recent years, however budget cuts 
have hampered these efforts. Furthermore, funds originally 
designated for IRM departments have been rerouted to the CIM 
initiative. New developments and modernizations have been 
severely restricted to mission essential programs. Moreover, 
the vast size and the large number of components within the 
DON make documentation and planning an enormous assignment. 
The DON issued the Information Resources Strategic Plan of 
April 1991 as a primary reference to assist Navy components in 
defining their IRM requirements. The IRSTRATPLAN is a timely 
document which clearly defines the IRM mission and scope as 
set forth by the DON and is consistent with the CIM 
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initiative. The plan discusses five key issues which 
delineate the DON overall IRM strategy. These issues include: 

• Information architecture 

• Requirements, planning, budget, and execution 

• Acquisition process 

• Telecommunications and computing infrastructure and 
supporting technology 

• Workforce development. [Ref. 5: p. iii] 

The IRSTRATPLAN provides guidance necessary for each DON 
component to begin defining its IRM requirements. 

Information systems architecture methodologies are 
effective tools in creating strategic plans for an 
organization. Some of the methodologies that exist today to 
assist in the management of information resources are Business 
Systems Planning (BSP), Information Engineering (IE), and 
Enterprise Architecture Planning (EAP). While there is no 
consensus on which methodology is the "best", the underlying 
principle is the need for a comprehensive understanding of 
the flow of information within an organization and how that 
information is utilized, IS architecture provides 
organizations with the ability to assess their current 
situation and develop strategies for meeting future 
requirements. 
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Information systems architecture is a discipline designed 
to develop a road map of information requirements throughout 
an organization. Major components of IS architecture include: 

• Data architecture - physical mappings, corporate and user 
views. 

• Application architecture - business process groupings 
presented to the end-users. 

• Geographic architecture - maps the information 
requirements for strategic locations within the 
organization. 

• Technology architecture - determines the technology 
required to meet all other architectures. [Ref, 6: p. 17] 

Currently within DOD there exists a "multiplicity of 
unique information system architectures with incompatible 
hardware, software and communications networks." [Ref. 4: p. 
18] The inability to integrate systems prohibits essential 
sharing of data both within and across the services. The CIM 
initiative addresses this problem by mandating the use of a 
coiTUTion information architecture framework by the services to 
ensure standardization. Furthermore, it is essential that 
both CIM and non-CIM systems are capable of communicating. 

The purpose of this thesis is to provide the Naval Air 
Systems Command's (NAVAIR) Information Resources Management 
(IRM) Division (AIR-713) with an analysis of methodologies and 
tools to assist the division in creating an information 
systems architecture. The IRM division is responsible "for 
formulating policy, planning, budgeting, directing. 
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administering and exercising oversight of the NAVAIR IRM 
Program, for all non-tactical information systems {ISs} and 
associated resources." [Ref. 7: p. 1-1] The selection of 
standard methodologies and tools within CIM is not expected 
for at least another year. NAVAIR must select a broad 
methodology which has the ability to use many different 
techniques and tools, facilitating easy adaptation within CIM. 
NAVAIR will be setting its own IS planning standards to be 
promulgated throughout its command until the CIM standards are 
complete. 


C. RESEARCH QUESTIONS 

The questions this thesis will address are as follows: 


1. What is NAVAIR's current information systems architecture 
plan? 

2. What information systems efforts are currently being 
developed within NAVAIR? 

3. What "culture" exists in NAVAIR to enhance/deter the 
implementation of a new Information System Strategy? 

4. What methodologies are most effective in determining 
information systems requirements? 

5. How have lEF CASE tools changed in the last two years and 
do they have the capability to be integrated with other 
CASE tools? 

6. Which methodology and tools will be able to increase the 
effectiveness and efficiency of NAVAIR by improving the 
structures and uses of information? 

7. What are the benefits to NAVAIR exist from utilizing the 
methodology and tools selected? 
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Chapter II will provide an overview and comparison of 
methodologies available for architectures within the 
constraints set forth by CIM. The architectures discussed are 
Enterprise Architecture Planning and Information Engineering. 

Chapter III will provide NAVAIR with a baseline 
architecture from which to begin their overall IS plan. A 
baseline architecture corresponds to the Business Modeling 
phase of EAP, discussed in Chapter II. In addition, two 
previous NAVAIR architecture efforts will be analyzed: NAVAIR 
Division-04 (AIR-04) Information Strategy Plan (ISP) and the 
Component Information Management Plan (CIMP), 

Chapter IV will evaluate barriers to implementation of an 
IS architecture. It will provide some insight as to how to 
avoid and manipulate such barriers as: approaches to planning, 
organizational culture, political climate and senior 
management involvement. 

Chapter V will include conclusions and recommendations for 
NAVAIR Information Resource Management division. Future 
thesis topics will also be provided. 

Information systems architecture will prove to be a 
crucial tool for structuring and manipulating information in 
the future. NAVAIR needs an information architecture to 
document current systems and to determine where they would 
like to be in the years to come. With more reductions in the 
IRM budget expected, this thesis will provide critical 
research for NAVAIR with substantial savings of both time and 
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money. This thesis presents NAVAIR with an analysis of 
methodologies and tools which should prove useful in the 
creation of an overall information systems archtecture. 
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INFORMATION SYSTEMS ARCHITECTURE METHODOLOGIES 


II . 

A. THE NEED FOR AN IS ARCHITECTURE 

The need for information systems architecture has gained 
considerable momentum in recent years. Rapid advancements in 
computer and information technology have had an enormous 
impact on the organization's allocation of resources and more 
importantly on the strategic goals of businesses. 
Furthermore, "since the technology permits 'distributing' 
large amounts of computing facilities in small packages to 
remote locations, some kind of structure (or architecture) is 
imperative because decentralization without structure is 
chaos." [Ref. 8: p. 276] An IS architecture has become an 
essential requirement to the survival of any organization in 
today's information age. 

There is little consensus on the definition of, or 
procedures used, in an IS architecture. As mentioned in 
Chapter I it can be a "road map" or a "high-level map of the 
information requirements of an organization." [Ref. 9: p. 198] 
IS architecture can be used as a planning guide for "long- 
range development but also allow response to diverse short- 
range information system demands." [Ref. 10: p. 122] Each 
interpretation illustrates the importance of IS architecture 
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as a tool for docxwnenting and developing an organizations 
strategy for the future. 

Planned systems offer many potential benefits to an 
organization. The containment and reduction of costs has 
become vitally important to organizations today. 
Architectures facilitate reduction in data entry, increased 
productivity, and identification and elimination of complex 
interfaces between incompatible systems, all of which reduce 
costs. The increase in the timeliness of data and the access 
to shared data further contribute to cost savings as 
management is able to make better informed decisions. [Ref. 
11: p. 3EAP1-9] 

The phrase "potential benefit" is very significant in 
systems planning. Many different IS architecture 

methodologies are on the market today. While many 
organizations have attempted IS planning few organizations 
have succeeded in implementing them. Many obstacles must be 
overcome to effectively use any methodology: 

• Awareness/Recognition/Acceptance by top management 

• Commitment of resources (staff and funds) 

• Lack of credibility of planning leaders (IRM/DA) 

• Finding the 'best' methodology; Inadequate tools 

• Educating DP people in new technologies 

• Crises today leave no time for planning (other excuses) 

• Substantial up-front cost; Benefits difficult to measure 
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• Inaccessible or uncooperative users; Delegation. [Ref. 
11: p. 3EAP2-4] 

Of those obstacles listed above, support from top management 
and the commitment of resources are most critical. 

This chapter provides an analysis of one methodology that 
has emerged in the past few years. Enterprise Architecture 
Planning (EAP). EAP has been successfully implemented in 
Canada but is only now gaining recognition in the U.S. A 
comparison and contrast of EAP with the widely used 
methodology. Information Engineering, will conclude the 
chapter. 

B. ENTERPRISE ARCHITECTURE PLANNING 
1. Overview 

Enterprise Architecture Planning is "the process of 
defining architectures for the use of information in support 
of the business and the plans for implementing them." [Ref. 
11: p. 3EAP1-2] The key word in the above statement is 
"defining." Many earlier architectures attempted to design 
structures for the organization prior to defining the 
organization itself. EAP emphasizes the planning process from 
the initial decision to investigate IS architectures through 
to its implementation. The migration or implementation plan 
is one aspect of traditional systems planning methodologies 
which was rarely developed, and which resulted in many failed 
architecture attempts. 
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EAP is a data-driven approach rather than process- 
driven. A strong knowledge base of the organization is gained 
through the functional business model that is developed using 
EAP. The data architecture should be completed prior to the 
applications architecture to allow data dependencies to 
determine the overall plan. Furthermore, EAP allows for both 
short- and long-term planning which is critical to 
establishing operational and strategic goals of an 
organization. [Ref. 11: p. 3EAP1-7] 

There are many business benefits of EAP. Each of the 
following benefits works in conjunction with the potential 
benefits of planned systems mentioned earlier: 

• Perspective focus on strategic use of technology for 
managing data as an asset 

• Standard vocabulary facilitates communication, reduces 
inconsistency and data redundancy 

• Documentation increases understanding of the business 

• Process considers integration of current systems with the 
new 

• Cost-effective long-term solution considers rate of return 

• Methodology facilitates easier assessment of the impact of 
new systems 

• Modeling allows easier accommodation of dynamic business 
changes such as acquisitions, budget reductions, lines of 
business, etc. 

• Management participation provides a business perspective, 
credibility, confidence, and demystifies system 
development. [Ref. 11: p. 3EAP1-8] 
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Success is measured in Enterprise Architecture 


Planning as: the project was completed . the plan is being 

implemented , and "the architectures are used to guide the 
development and are maintained current." [Ref. 11: p. 3EAP2-1] 
The reason EAP has been successful is that it is not a 
technical document. The focus is on managing and planning. 
Furthermore, the commitment and support of management is 
gained at the outset and maintained throughout the process. 
Participation from management and end-users, with an equal 
representation of business and systems personnel, allows for 
greater ownership of the project and greater cooperation. An 
"acceptable balance of scope/objectives vs. level of detail 
vs. resources and time committed" also adds to EAP successes. 
[Ref. 11: p. 3EAP2-5] The organization's culture is 
identified early and the plans are developed to fit the 
culture. A completed architecture that ignores corporate 
culture will not be accepted and will ultimately fail. 
Intermediate deliverables are distributed within the 
organization to provide constant communication and feedback 
and ensure ownership is continued. 

Throughout the phases of the project, the 80/20 Rule 
must be followed, i.e. capture 80 percent of the knowledge and 
information benefits with 20 percent of the effort. 
Planning is imperfect and time consuming. The EAP methodology 
insists that the best personnel be used. To do this, the 
"best" people must take time away from other tasks which 
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ensures productivity during each meeting resulting in 
completing phases on schedule. 

2. Methodology 

The components of Enterprise Architecture Planning are 
managed in a pyramid formation: 




A great deal of effort is entailed in the top level, Planning 
Initiation. One premise of EAP is that no methodology can be 
successful without ensuring an effective and efficient Plan. 
The second level, Business Modeling and Current Systems & 
Technology, determines and documents where the organization is 
today. Once level two is complete, level three, 
architectures, defines where the organization wants to be in 
the future. Notice that data architecture is completed prior 
to applications architecture. The final level, 
Implementation/Migration Plans, provides the vehicle for the 
organization to attain its goals. The order in which each 
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component is conducted is vitally important to the success of 
an EAP project as each preceding component ensures a strong 
knowledge base for the component following. 

The Planning Initiation phase is comprised of seven 

steps: 


1 . 

2 . 

3 . 

4 . 

5. 

6 . 

7 . 


Determine Planning Objectives, 
Suitable Business Unit 

Create a Vision (Initial Meetings 

Adapt a Planning Methodology 

Arrange for Computer Resources 

Assemble the Planning Team 

Prepare Detailed Schedule and 
Workplan) 

Obtain/Confirm Commitment and 
Presentations) [Ref. 11: p. 3EAP3- 


Scope and Select a 
with Management) 


Cost Estimates (EAP 

Funding (Executive 

2 ] 


Defining the "enterprise" is extremely important in 
the planning stage. An enterprise may include the entire 
organization, a division or profit center, or possibly a 
subsidiary or functional area. In selecting the business unit 
for EAP, the following characteristics must be evaluated: 


FAVORABLE CHARACTERISTICS 


• Has current strategic long range business plans 

• Emphasis on quality improvement programs 

• Need to integrate and share data 

• Unsuccessful DP projects or severe cost overruns 

• Budget approved for major new system 

• Ma^or business changes anticipated 

• Extensive management changes or reorganization 
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• Able and willing to design architectures 

UNFAVORABLE CHARACTERISTICS 

• Opposites of the above 

• Shortsighted management (time, budget, other excuses) 

• Recent "unsuccessful" planning attempts 

• Hostility or resentment towards systems people 

• Uncooperative "hands-off" attitude (delegation) 

• Experiencing less profit, potential downsizing 

• Lack of or disregard for standards or plans [Ref. 11: p. 

3EAP3-5] 

Favorable characteristics should outweigh unfavorable 
characteristics, and a strategy should be formulated to 
overcome potential obstacles. 

An adequately defined scope is crucial to a project if 
it is to meer the needs of an organization. It should include 
all areas that share data, or need to share data. A strategy 
is developed to answer any unfavorable characteristics 
identified. It is important that the objectives are written 
in simple, concise, nontechnical language, focussing on the 
benefits to the organization. The risk of a too narrowly 
defined scope is that the architecture will be incomplete and 
independent causing integration problems. Alternately, if the 
scope is too broad the project will have insufficient detail 


and take 

too 

much 

time. 

Any issues or problems 

must 

be 

addressed 

at 

this 

stage 

to have complete confii 

dence 

of 

success . 

[Ref . 

, 11: 

p. 3EAP3 

-4] 



A 

cri t 

:ical 

success 

factor of this planning 

phase 

is 


the need to understand corporate culture. While much 
attention has been given to culture in recent years, there is 
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little consensus on its definition. One definition of culture 


is : 

a pattern of basic assumptions-invented, discovered, or 
developed by a given group as it learns to cope with its 
problems of external adaptation and internal integration- 
that has worked well enough to be considered valid and, 
therefore, to be taught to new members as the correct way 
to perceive, think, and feel in relation to those 
problems. [Ref. 12: p. 9] 

Another definition states that "the purpose of culture is to 
provide members with a sense of identity and to generate a 
commitment to beliefs and values that are larger than 
themselves." [Ref. 13: p. 14] 

Understanding and documenting culture is quite 
complex. Corporate cultures are a reflection of their leaders 
and without their visible support, an architecture effort will 
encounter "a counter-cultural effort to implement cooperation 
and some centralized decision making." [Ref. 14: p. ID/2] 
There are several different techniques for evaluating cultures 
(Figures 1 and 2). These methods identify specific 
characteristics (i.e. entrepreneurial, competitive, 
participative) which exemplify the organization. Through 
careful examination of an organization's culture an EAP plan 
can be developed within the constraints of the culture, 
ensuring critical commitment and cooperation throughout the 
organization is achieved. 

A vision statement merges the project's scope with the 
organizational culture to invoke enthusiasm and support. It 
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and Change [Ref. 13] 
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depicts the target environment the enterprise is working 

towards. The most famous vision statement was delivered in 

1961 by President John Kennedy: "’We will put a man on the 

moon, and return him safely to earth, by the end of the 

decade.’" [Ref. 14: p. 6] Another example would be a 

president of an insurance company wanting policy holders to 

complete their intended objective in a single telephone call. 

A vision statement is simply one that identifies the 

organization’s aspirations for the future. 

A unique and critical aspect of EAP is that other IS 

methodologies can be incorporated into the project. Again, 

EAP is a defining and planning process, and therefore, any 

methodology that can assist in the process is viable. The 

following methodologies and teachings can be applied to EAP: 

--> IBM’s BSP, BSPI, and BSPX 

--> Books by James Martin and Others 

--> Inf ormation Engineering (JMA, PIM, Knowl edgeware , PDC) 
--> SSP and TSP (Holland) 

--> System Architecture (Nolan) and 

Investment Strategy (Norton) [Ref. 11: p. 3EAP3-12] 

The methodology chosen should be easy to understand, 

compatible with the existing culture/politics, utilize 

automated tools, and produce a long-range implementation plan. 

Consultant firms trained in EAP are also an option, but can be 

costly and time consuming. Once selected, the methodology 

must be tailored to meet the needs of the particular 

organization. 
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The steps involved in the Planning Initiation 
component all combine to win commitment from top management. 
The project is scoped and the enterprise selected, a vision 
statement is promulgated which encompasses the entire 
organization, a methodology is adapted, dedicated computer 
resources are arranged, a ski lied and highly credible planning 
team assembled, and schedules and estimates prepared, all with 
the expressed purpose of the executive presentation(s). This 
IS a very political process and must be recognized as such. 
Proving the need for an EAP, or equivalent architecturing 
effort, is essential. Themes should be used which provide 
ownership throughout the organization (management, 
programmers, end-users) with phrases such as: "We must work 
together toward the same goal". The commitment gained in 
Planning Initiation must be attended to and nurtured 
throughout the E.AP project. 

Once the planning phase has been completed, commitment 
achieved, the EAP team shifts to level two; understanding and 
documenting current organizational structure and business 
functions. Using the toolset selected earlier, new 
organization charts are created to include organization units, 
reporting structure, locations, as well as business goals and 
objectives. This can he a very time consuming process and the 
team must stay quite focused. [Ref. 11: p. 3EAP4-8] 

Identifying and defining business functions seeks 
answers to the question "What is it that 'We' do?" A function 
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is " any set of actions performed in the course of conducting 


business" and "is defined entirely by its subfunctions." [Ref. 
11: p. 3EAP4-9] Functions should be defined along functional 
lines versus reporting lines. Decomposition of functions 
continues "until the functions tend to be single action 
oriented, executed repeatedly and have identifiable outcomes." 
[Ref. 11: p. 3EAP4-10] Enterprise surveys, interviews of 
personnel, are an excellent source of information for 
identifying business functions. The functional business model 
(FBM) should be compiled using the toolset chosen, distributed 
within the organization and presented by a well respected team 
member. 

The Current Systems and Technology component is 
frequently a subproject that can begin prior to Planning 
Initiation and can be conducted concurrently. The Information 
Resource Catalog (IRC) produced in this phase is a valuable 
document for the architecture components. The IRC entails the 
following: 

• Reference to All Information Resources 

Application Systems 

Data (Inputs, Outputs, Files/DBs) 

Technology Platforms 

• Distribution of Information Resources 

• Information Locator for Management, Orientation for MIS 
Personnel 

• Baseline for Long Range Planning and Highlights 
Oppor tuni1 1 es 

• Budgeting and Cost Control Decisions 
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• Quick Success at Reasonable Cost, Establishes Credibility 

• Internal Use of Documentation Tools [Ref. 11: p. 3EAP6-2] 

The IRC is then distributed to the DPs and end-users and 
becomes the baseline for the data architecture phase. 

The third level in the EAP pyramid consists of the 
three architectures. Each of these conforms to traditional 
architectural procedures and guidelines. First, the steps 
involved in creating a data architecture are: 

1. List Candidate Entities 

2. Define the Data Entities, Attributes and Relationships 

3. Relate the Entities to the Business Functions 

4. Distribute the Data Architecture 

An entity is defined as: "any person, place, concept, thing, 
or event that has meaning (information) in the context of the 
business ('an aggregation of data needed for a specific 
purpose') [Ref. 11: p. 3EAP7-3] Once identified, entities 
provide valuable knowledge of the characteristics of data and 
how data relates within an organization. Entity-relationship 
diagrams are helpful in this phase to illustrate both simple 
and complex interrelationships that exist within the data 
architecture. 

In relating entities to functions, toolsets generate 
matrices using the lowest level of each function. A data 
entity is identified as 
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• Created 


• Updated 

• Referenced 

Only significant relationships, based on entity usage, should 
be included in the matrix. 

The deliverable for the first component is the Data 
Architecture Report (DAR) which includes a list of entity 
names, complete entity definition, Entity-Relationship 
Diagrams, Entity Usage Matrices, and any Data Flow Diagrams. 
An introduction provides a detailed explanation on how to 
interpret the DAR. 

The second architecture component is the applications 
architecture. Using the DAR, FBM, and the IRC, all possible 
applications are listed and defined. Application definitions 
entai 1 : 

• brief purpose 

• general description and capabilities 

• business opportunities and benefits (tangible, intangible) 
[Ref. 11: p. 3EAP8-5] 

This definition should focus on what it does, independent of 
technology, and not how the application accomplishes its 
tasks. 

Matrices are again utilized to illustrate 
relationships between applications and business functions and 
organizational units. The matrices depict the support status 
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of the applications: current, modify, replace, planned, 

needed. Furthermore, an Impact Analysis is conducted to 
determine if existing applications are to be: 

• completely replaced 

• partially replaced and modified 

• retained with minimal enhancement 

The last phase, technology architecture, begins with 
designing the data/applications distribution architecture. In 
this step, business locations are associated with data and 
applications architectures; traffic volumes are estimated. 
Next, the technology platforms (layers) are defined. The 
technology configuration (i.e., hardware, software, networks, 
communications) is selected and costs estimated. Diagramming 
the configuration is helpful in formulating a vision of how 
the application and data relate to the technology chosen. 
Estimates of the resources required are also needed to assess 
the viability of the technology: 

• people (number S types), organizational units and 
structure 

• business impact, procedural changes 

• policies and standards 

• acquisition and capital expenditures [Ref. ll:p. 3EAP9-4] 

The final step of the technology architecture is to 
confirm applications and technology. At this stage, the 
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purpose, inputs and outputs for each application are reviewed 
and any changes to the FBM noted. A description of the 
"technology 'vision'" is essential in illustrating the 
benefits and opportunities that will be available with 
implementation of the architecture. [Ref. ll:p. 3EAP9-7] 

While each component resembles traditional 
architectures, attributes exist that are unique to EAR. 
Throughout this level, team interaction and discussion is 
significant and essential. The team composition of both 
systems and business personnel guarantees the documents will 
be comprehensive and easy to read. Creativity, inventiveness, 
and the use of team brainstorming are effective skills 
utilized in each phase. Furthermore, the team must determine 
how they define "consensus" as EAP requires it on the 
definitions cf entities and applications. As mentioned 
earlier, communication both within the team and throughout the 
organization is important to gain feedback, to confirm that 
the project is meeting the needs expressed in the planning 
phase, and to maintain commitment from top management and the 
organization. 

The final stage of the EAP process is the phase most 
neglected by other IS architecture methodologies. The 
Implementation/Migration Plans component is what distinguishes 
EAP most from other methodologies. This component is 
comprised of three phases: Data Development Plan, Planning 
Conciusicr., and Transition to Implementation. 
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The Data Development Plan sequences and prioritizes 
the applications and estimates the effort, resources, 
schedules, costs, and benefits. Critical success factors 
(CSF) are determined and recommendations (desired management 
decisions) are made in this particular phase. The CSFs "are 
conditions that will contribute to or enable the 
implementation of the plan to proceed toward a successful 
conclusion which are either not presently in place or are in 
jeopardy of an unfavorable change." [Ref. 11: p. 3EAP10-15] 
Some common CSFs are: 

• Immediate initiation of the Transition Phase 

• Approval of plan (with initial projects) 

• Adopting new system development methods (I.E., 0-0) 

• Evaluation/Selection/Acquisition/Instal1ation of 

- hardware platforms (network, connectivity) 

- software packages 

- CASE 

• Standards and Procedures 

• Approval of budget 

• Reorganizing I.S.; Shifting responsibi1ities[Ref. 11: 

p. 3EAP10-16] 

Training requirements for each phase of implementation are 
also determined, to include DP department personnel and 
applications and technology end-users. 

The second phase of implementation is Planning 
Conclusion. The final EAP report is prepared and must be 
consistent with the corporate culture. Strong, emotional 
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wording, unsubstantiated statements, unlabeled opinions, and 
controversial subjects should be omitted from the report. 
[Ref. 11: p. 3EAP11-4] Presentations are prepared and 
delivered to management "to explain the results of EAP and the 
plans, and ultimately to obtain their approval or support to 
proceed with the implementation." [Ref. 11: p. 3EAP11-6] 
Presentations are also made to every department within the 
enterprise. 

The final phase of the entire EAP project is 
Transition to Implementation. There are eleven steps to be 
completed: 


1. Plan the Transition 

2. Adopt a System Development Approach 

3. Arrange for Computer Resources 

4. Refine the Architectures 

5. Institute Organizational Changes 

6. Recruit Implementation Personnel 

7. Provide Thorough Training 

8. Establish Programming Standards 

9. Establish Procedural Standards 

10. Develop a Detailed Workplans for the First Group of 
App1 1 cations 

11. Confirm the End of Transition [Ref. 11: p. 3EAP12-2] 


Evident by this extensive list of steps is the 
comprehensiveness and attentiveness of EAP to validate the 
implementation process and guarantee success. A transition 
phase workplan is developed to address and schedule the above 
steps, as well as: plan for the acquisition and installation 
of hardware and software, develop a strategy for managing 
political obstacles, determine approaches to and projects for 
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prototyping, and schedule the recruiting and training of 
personnel. The workplan is a thorough attempt to confirm that 
all avenues and obstacles have been examined prior to 
implementation. 

Essential throughout the EAP process, and specifically 
during the transition phase, is the need to maintain high 
enthusiasm and momentum for both the team members and the 
organization. Steady progress is imperative. Resistance to 
change can retard, if not destroy, an implementation plan and, 
therefore, must be effectively managed. The transition phase 
requires strong leadership and direction to allow 
implementation to proceed. 

3. Assessment of EAP 

Enterprise Architecture Planning is a thorough 
methodology for information systems planning. From the 
selection of team members, to the care and attention given to 
each step of each component, EAP is exhaustive in its efforts. 
Costly, redundant systems are identified and eliminated. 
Applications are developed quicker and along functional lines, 
increasing productivity and improving user skills. Critical 
management decisions are based on more accurate and timely 
data, effecting a more stable, cost-efficient organization. 

EAP is an objective and impartial approach to IS 
architectures. Organizational participation allows everyone 
to take ownership of the effort. The continuous communication 
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and distribution of intermediate deliverables provides 
constructive feedback to verify the project is meeting the 
needs of the organization. A viable migration strategy is 
developed for both long and short term plans to effect smooth 
implementation. The flexibility of EAP allows organizations 
to rapidly adapt to and survive in dynamic environments. 

C. INFORKATION ENGINEERING 
1. Overview 

Information engineering (IE) is a widely recognized 
methodology in the field of Information Systems. Information 
engineering "refers to the set of interrelated disciplines 
that are needed to build a computerized enterprise based on 
information systems." [Ref. 17: p. 24] As a data-driven 
approach, IE has traditionally confined itself to data and 
data architecture. Other characteristics of IE include: 

• It is driven by the user. 

• It anchors data processing expenditure in top management's 
needs and goals. 

• It identifies how computing can best aid the strategic 
goals of management. 

• It is based on easy-to-understand diagrams. 

• It employs a steadily evolving central repository of 
knowledge about the enterprise. 

• It uses CASE tools to link diagrams with code generators 
and fourth-general 1 on languages. 






• It uses prototypes. 

• It assists information center activities. 

• It is integrated throughout the information systems 
function. 

• Its goal is full automation of the database and 
application development process. [Ref. 17: p. 24] 

Information engineering merges the talents of users, 
management and DP personnel in an effort to "identify, 
implement and process the data that supported the business." 
[Ref. 16: p. 11] Users and managers are now able to complete 
much of the design requirements resulting in more complete 
specifications which reduces the time required for application 
development, thereby reducing the application backlog. 

There are several different versions of information 
engineering currently on the market. One interpretation by 
Clive Finkelstein provides extensive integ-ation of CASE tools 
throughout the IE process. The data modeling components of 
this version of IE closely coincides with the architecture 
requirements of NAVAIR. The information engineering 

methodology discussed in the next section is strictly that of 
Clive Finkelstein. 

2. Methodology 

Beginning in 1976, IE's primary focus was on data base 
design. Several years later it incorporated such techniques 
as data and information analysis and information systems 
design. Currently, information engineering has evolved to 
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include strategic, tactical and operational data modeling. 
But the focus has not shifted from data. IE's Data Modeling 
identifies and defines entities and produces Entity 
Relationship Diagrams. However, IE extends that process to 
include data mapping which resembles the normalization process 
used in Data Base Management Systems (DBMS). The purpose of 
the normalization process is: 

The application of a formal set of rules which determine 
those key attributes which uniquely identify each data 
attribute, and which place each attribute in an entity 
where it is fully identified by the whole primary key of 
that entity. [Ref. 16: p. 94] 

The data modeling process is extensive in the effort to 
capture all data utilized by an organization. 

There is a significant emphasis placed on strategic 
and tactical planning by IE. Strategic management is 
accomplished through "communication, execution and management 
of strategic planning" which leads to successful strategic 
imipl ementation. [Ref. 16: p. 158] Two main types of strategic 
planning exist: corporate and systems. Corporate planning is 
attended to by top management while systems planning has been 
a function of DP departments. To align these two, systems 
planning should be incorporated into the corporate planning 
department. 

Several problems which arose from traditional 
strategic planning are: [Ref. 16; p. 160] 
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strategic Planning 


Strategic Implementation 


Long feedback cycle (3-5 years) 
Ineffective performance 
monitoring 


Strategic Management 


Strategic planning in information engineering can be 
accomplished using either a formal or informal approach. 
Although the processes are somewhat different, both approaches 
result in a strategic statement which entails: 

• Mission and purpose. 

• Concerns and issues. 

• Goals and objectives. 

• Policies. 

• Strategies and tactics. [Ref. 16: p. 175] 

The informal planning approach also includes tactical 
statem.ents which define the objectives and procedures that 
will assist the organization in rapidly adapting to changes in 
their environment. 

Information engineering has three primary phases: 
Analysis Phase, Design Phase and Generatior', Phase. During the 
analysis phase, data and informativ^n required at the strategic 
and tactical management levels are defined using the strategic 
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and tactical statements developed prior to the start of the 
project. The steps involved in this phase are: 

1. Project scope 

2. Strategic modeling 

3. Tactical modeling 

4. Operations modeling 

The strategic model focuses on high-level, senior management 
issues with long-term goals, while the tactical model 
represents middle management interests and short-term 
objectives. An operations model concentrates on the day-to 
day operations and objectives of an organization. 

The users are primarily responsible for the analysis 
phase. IE techniques and expert systems are employed to 
capture the users expert knowledge. The effect of this phase 
is "the progressive definition of the data resource." [Ref. 
16: p. 229] The data is then examined in the design phase to 
identify common and redundant data, and is mapped to users and 
functions within an enterprise. It is recommended that the 
analysis and design phase be conducted concurrently to 
increase productivity. 

The design phase is automated using expert design 
tools. An exper' .ctionary is used to check the consistency 
and accuracy of data definitions used by all three models. 

data i-• '^ombined into integrated strategic, tactical 
and operations models, and become inputs to the final phase. 
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The generation phase defines implementation strategies 
appropriate to each part of the integrated strategic and 
tactical models. It determines the hardware, software 
and communication facilities, and the physical design and 
development of defined information systems and expert 
business systems. [Ref. 16: p. 231] 

Conventional files, DBMS products, 3GLs and 4GLs, or expert 
systems may be used to represent the data in the applications 
development process. This phase defines the physical 
implementation of data, systems and reports. 

3. Assessment of Information Engineering 

Information engineering results in the construction of 
a data architecture. Data that is vital to the enterprise and 
the decision making process is identified and documented. IE 
is "objectives driven" in that goals and objectives are set 
forth for all levels of the organization. Also, as a user 
driven methodology , information engineering extracts essential 
knowledge to confirm that applications meet the users' needs. 

Information engineering is an evolutionary process 
with data being constantly elaborated and enhanced, as well as 
consolidated when redundancy is evident. Furthermore, IE 
provides rapid feedback from management on strategic 
alternatives through the use of what-if scenarios. As a 
highly automated methodology, IE relies upon data 
dictionaries, data bases and knowledge bases which are updated 
automatically affecting consistency and integration of models. 
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D. COMPARISON OF ENTERPRISE ARCHITECTURE PLANNING AND 


INFORMATION ENGINEERING 

Enterprise Architecture Planning and Information 
engineering are both data-driven approaches. EAP is a 
planning methodology whereas IE is a highly developmental 
methodology. The strategic planning conducted in IE occurs 
prior to the official start of the project. Planning within 
EAP is conscious and deliberate from the beginning through 
implementation. Moreover, the structure of each methodology 
is quite different. EAP incorporates three levels comprising 
seven phases in its methodology whereas IE has only three 
phases. The few corollaries that can be drawn between EAP and 
IE primarily correspond to the data modeling phase. 

The most significant benefit of information engineering is 
the development of, in EAP terms, a data architecture. 
However, IE fails to adequately satisfy the application and 
technology architecture needs of an organization. The 
combination of the three architectures is important for 
mapping current data to future requirements. The 
architectures also provide the necessary documentation of 
shared data, thereby creating systems and applications which 
support the organization. IE also does not address the 
implementation phase to the degree EAP does. The 
implementation plan seeks to identify all potential obstacles, 
set milestones, and is structured to maintain organizational 
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commitment. This phase is essential to the success of an IS 
architecture. 

Enterprise Architecture Planning is an extensive and 
exhaustive methodology with the primary objective of 
implementing a project. The attentiveness to planning as an 
integral part of the whole project sets this methodology apart 
from all others. The ability to integrate other methodologies 
adds flexibility and credibility. Information engineering can 
be an excellent tool within Enterprise Architecture Planning, 
but as a stand alone methodology, it lacks the comprehensive 
characteristics and components of EAP. 

To support NAVAIR in incorporating EAP principles in their 
architecture effort, a baseline architecture is proposed in 
the following chapter. 
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Ill. 


A BASELINE ARCHITECTURE FOR NAVAIR 


A. PREVIOUS ARCHITECTURE EFFORTS 
1. AIR-04 ISP 

The Aviation Logistics department of the Naval Air 
Systems Command published the AIR-04 Information Strategy Plan 
(ISP) in March of 1989. The ISP was based largely upon a 
combination of IE methodologies. Although the effort devoted 
to this plan was extensive, it was not successful by EAP 
standards, since it was not implemented. The most significant 
problem which affected every aspect of the project was the 
lack of a clear and concise scope which had the consensus of 
the participating team members, [Ref. 17: p. 9] 

The overall scope of this project was established by 
departmen* , AIR-04, and not by functional areas within NAVAIR. 
This resulted in an inability to adequately document areas 
outside of AIK-04. Furthermore, the functional areas chosen 
by the ISP team members were along the following departmental 
versus functional lines: Administrative Support, Policy and 
Planning, Property Management, Program Management, Operations 
Support, Financial Management. The AIR-04 ISP failed to 
define and document the information flows in sufficient 
detail, ar well as how information is shared, and therefore. 
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could not be effectively implemented within the Aviation 
Logistics department or NAVAIR. [Ref. 17: p. 33] 

2. NAVAIR GIMP 

The Component Information Management Plan (GIMP), 
promulgated annually, sets forth NAVAIR's policy for 
information resources/information systems (IR/IS) support. 
The GIMP "reflects a critical analysis of IR/IS requirements 
and priorities" [Ref. 18: Foreword] and GIMP incorporates the 
Information Requirement Plans (IRP) which are divided into 
seven functional areas: 

• Logistics 

• Systems and Engineering 

• Contracts, Administration and Business 

• Financial Management Systems 

• Local Area Networks 

• Local OA/AIS Systems 

• Support Systems 

Within each functional area are the listings of all 
information systems which support the various NAVAIR 
information requirements. The IRP provides substantial detail 
on the information requirements, management, resource support, 
architecture, and resource requirements (budget) of each 
system. 


40 








while the CIMP is partitioned initially by functional 
areas, the information systems within eauh aiea are net. 
Furthermore, no mission statement or executive overview is 
provided as justification or support for the functional area. 
The attention given to individual systems needs to be extended 
to the functional areas to ensure cohesiveness and validity of 
existing systems. 

B. A BASELINE ARCHITECTURE 

The AIR-04 ISP and the CIMP contribute valuable 
information and lessons learned to begi,; baseline 
architecture. This effort is not intended to be comprehensive 
but rather a starting point, implementing EAP techniques, to 
assist NAVAIR in identifying key steps in developing an 
overall IS architecture. The baseline architecture coincides 
with the Functional Business Model (FBM) discussed in Chapter 
II, and focuses only on the Logistics functional area. 

Beginning with the deficiencies noted in Section A, 
functional areas must be defined by what NAVAIR does. The 
functional areas designated by the CIMP are sufficient for 
this purpose (Figure 3). To determine the functional areas 
that exist within Logistics, a comparison of the information 
systems is required. Twenty systems are currently supported 
by Logistics (Figures 4 and 5). The highlighted words in 
Figure 5 denote common characteristics of these functions/ 
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Flgur* 3. MXVAIK Fimotlonal Areas [Ref. IB] 
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Figure 5; Logistics Information Systems [Ref. 18] 
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systems. Compiling like systems results in five functional 
areas: Maintenance, Material/Supply, NADEP (NAVAVNDEPOT), 
Training, and Weapons (Figure 6). 

In reviewing Figure 6, several factors become evident. 
First, many of the functional areas have numerous systems 
which indicates possible redundancy. Furthermore, within each 
area, there is at least one major information system which may 
be able to subsume some or all of the smaller systems. For 
example, the Naval Aviation Depot has five information 
systems, each using some data from the others. The Naval 
Aviation Depot Information Management (NADIM) seems to be a 
comprehensive system which may be able to incorporate others 
and thus reduce redundancy. One peculiarity arises in the 
Material/Supply functional area; SUDIS is unique system 
designed specifically for Point Mugu. It may be possible for 
that system to be subsumed by a larger IS or within another 
functional area, or based upon its "unique" contribution to 
that functional area, remain unchanged. 

Another factor is that within most of the functional 
areas, functional decomposition can be continued facilitating 
further consolidation or identification of redundancy. Within 
the Weapons area, three subfunctions are identifiable by their 
single action orientation (Figure 7). Finally, several 
system,! can be assigned to more than one functional area. 
This IS acceptable as long as the information flows are 
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Figure «. Logistics Functlonsl Aze&s (NEW) [Ref. 18] 
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correctly identified, documented, and any redundancy 
eliminated. 

Upon analysis of the budget sheets provided for each 
information system, it is evident that NAVAIR is consolidating 
systems within functional areas (Figure 8). Again using 
Weapons, individual budget sheets for AWARS and MARS indicated 
that these I3s cease to exist as standalones in FY91 and 
become applications of AWIS. Another IS, CADMSS, is also 
integrated into AWIS. however, a description is not provided 
in the CIM?. The budget implications for functional areas are 
best identified if budget sheets are consolidated. The sheet 
for Weapons gives valuable insight into the allocation and 
appropriation of funds and where consolidation of resources 
may be beneficial. 

As mentioned with regard to the AIR-04 ISP, true 
functional areas cannot be sufficiently determined without 
evaluating NAVAIR as a whole. Many of these systems are used 
by other departments and functional areas. The entire 
organization must be taken into consideration to attain a true 
picture of how information is utilized within NAVAIR. 
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Figure 8: Weapons Budget Sheet 
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IV. 


OVERCOMING BARRIERS TO IMPLEMENTATION 


Numerous information systems architectures have been 
attempted by civilian and government organizations. However, 
few IS architectures have been implemented and utilized. 
Internal and external environments affect every stage of the 
planning process. These environments can create barriers to 
im.plementation and must be managed throughout the entire 
effort . 

NAVAIR faces four barriers to successful implementation of 
their architecture. 


1. Inconsistencies in approaches to planning profoundly 
affect the portability of applications and the capability 
to integrate systems. Planning must be initiated at a 
level that ensures information systems evolve according 
to the needs of the enterprise. 

2. Misinterpretation of organizational culture can lead to 
extreme opposition to an IS effort. The culture 
determines how best to present and attain support for the 
project . 

3. Fluctuations in political climate, primarily within DOD, 
have a direct impact upon the priority an IS architecture 
receives. The internal and external environments must be 
stable and well managed to guarantee consistent backing. 

4. Inadequate senior management involvement will reduce the 
effectiveness and efficiency of information systems. The 
effort must have substantial organizational importance to 
secure commitment and support from all members of the 
organization. 
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These barriers can seriously impede the progress of a project, 
resulting in an ineffective effort and even failure of a 
project. 

A. APPROACHES TO PLANNING 

Planning must be initiated at a level that ensures 
information systems evolve according to the needs of the 
enterprise. If the approach is too localized or departmental 
it will lack connectivity to the overall organizational plan. 
Conversely, if the approach is too broad, the architecture may 
lack sufficient detail to develop operational information 
s y s t ems. 

The two approaches to business planning are bottom-up and 
top-down. Bottorr.-up planning, the most commonly used, is 
conducted at the departmental level and is primarily concerned 
with preserving budgets rather than addressing business 
functions. This approach often creates plans which are 
independent of other activities within the organization 
resulting in non-standard, non-integrable systems that rarely 
meet or comply with organizational strategies. 

The second approach, top-down, dictates that planning is 
initiated at the top through a collaborative effort between 
senior management and functional managers. Greater commitment 
from; subordinates is gained through this process. 
Fur chermiore, consistency with overall goals and objectives is 
maintained. However, top-down planning may inadvertently omit 
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vital information known only by users deep within the 
organization. 

To prevent planning from becoming an implementation 
barrier, the best approach is a combination of the two. 
Direction and strategic guidance are provided at the top, 
while detailed planning formulation and implementation is 
conducted deep within the organization. Senior management 
monitors and reviews plans to ensure congruity and 
cohesiveness for effective implementation. 

Functional managers are critical to the planning process 
in that they are best able to identify their detailed IS 
requirements and help correlate or translate them into the 
overall plan. Furthermore, functional managers must be able 
to justify how their current or future systems impact the 
organ! sat i on'.s mission. For example, if a functional area 
within NAVAIR requires a new material management IS, its 
impact on the organization's overall mission and other ISs 
must be explicitly defined to top management. The impact 
statement should include the drastic reduction in the location 
and dispatch time required for aviation parts and the benefits 
of the elimination of two information systems. 

The IS architecture team must effectively illustrate the 
value of this planning approach to obtain the organization's 
endorsem.ent and to guarantee the process is valuable. The 
effect of systems that are inconsistent with, or that have 
little relevance to, the organization's overall mission 
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(whether imprudent, redundant, or non-integrable) must be made 
clear by the team. 

B. ORGANIZATIONAL CULTURE 

The disregard, or inaccurate identification, of corporate 
culture will result in serious resistance to implementation. 
As discussed in chapter two, "the purpose of culture is to 
provide members with a sense of identity and to generate a 
commitment to beliefs and values that are larger than 
themselves." [Ref. 13; p. 14] These beliefs and values can 
blind management to the significance of changing their 
environm.ent as well as inhibit change if management considers 
their present practices successful. 

Changing corporate culture is a very complex and delicate 
process, especially if it has been perpetuated in the 
strictest traditions over time, as with the military. 
However, the consequence of not transforming the structure is 
the perpetuation of ineffective, redundant, costly systems in 
an era cf diitiinishing resources. Organizations should be 
configured based on their information needs and how 
information supports their overall missions. This could 
result in an alteration of the organization's culture. 
However, if a change is warranted, a plan must be developed 
within the fraiTiework of the existing culture, identifying any 
potential cultural risks. [Ref. 13: p. 15] Since corporate 
culture represents the beliefs and values of its leadership. 
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it is imperative that any paradigm shift from a department to 
functional area organizational structure be initiated by top 
management. Further, the shift must be frequently monitored 
and post-implementation criteria established to prevent the 
reduced impact of change over time. 

It is unrealistic for management and staff to expect 
overnight benefits from an IS architecture (Figure 9). The 
immediate impact of change will be reduced efficiency and 
effectiveness, confusion within the organization and an 
increase in staff turnover. [Ref. 19: p. 8] The intermediate 
impact is the increase in resources expended and the temporary 
erosion of the organization's value system as "a new corporate 
equilibrium is reached." [Ref. 19: p. 8] The desired long¬ 
term effect of change is "on efficiency of operations (costs); 
effectiveness of products or services; quantity and quality of 
inf orm.ation; and corporate culture/management culture." [Ref. 
19: p. 8] 

The human element must be managed to affect a cultural 
change thereby implementing a new technology. No longer is it 
sufficient to identify the process and technology needed to 
increase the effectiveness and efficiency of a business. It 
IS vital that the members of the organization accept and 
support the recommendations for implementation to achieve 
success. 
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C. POLITICAL CLIMATE 


An information systems architecture is not so dependent on 
the importance cf its ideas and principles as it is on the 
charisma and the credibility of its leadership. Currently, 
the CIM initiative, and more specifically Paul Strassman, is 
the driving force behind all DOD IRM and ADP issues. New 
developments and modernizations have been curtailed and the 
entire Department of Defense is in a state of flux waiting for 
firm policy decisions and mandates, as well as product 
selection. Buzzwords depicting CIM's direction change 
frequently. Current buzzwords include re-engineering, 
reusable code and benchmarking. Two concepts that have had 
decisive political impact on information technology (IT) 
within DOD are TQM and, most recently, IDEF. 

1 . TQM 

Total Quality Management (TQM) became a military, and 
political, concept in 1990. It is an approach to changing 
management practices which have been in effect for decades. 
"TQM IS a management philosophy and approach that brings 
together a complete set of management principles and 
techniques for an organization to survive and grow in the 
1990's" [Ref. 20: p. 7-1] IS/IT efforts are required to be 
aligned with TQM. IT supports TQM as a "holistic management 
approach"; 
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• Considers the total system (i.e., all management processes 
and their interfaces)...al1 of the components within a 
system and the people that work in it must work toward the 
aim of the organization. 

• Employs a complete set of hard (engineering) and soft 
(personnel) management sciences. Leadership behavior must 
be fine-tuned to energize each unique individual to think 
and work toward his or her potential. Team efforts should 
be expected to produce results that are greater than the 
sum of the individual parts. 

• Involves and benefits managers, employees, customers, and 
suppliers. [Ref. 20: p. 5-1] 


The impact of IT on TQM is that it provides the means for 
determining what processes need improving and the analytical 
tools to complete the task. TQM is designed to force the flow 
of information both up and down the chain of command, while 
assuring consistency and accuracy of meaningful and shared 
data. 


The combination of IT and TQM promises to give 
organizations a definitive strategic advantage (Figure 10). 
The precepts of TQM coupled with those of CIM require senior 
officials and IS/IT teams to possess the political savvy to 
ensure all specifications have been suitably addressed and 
documented. 

2. IDEF 

Integrated Definition (IDEF) language is the latest 
methodology to be selected by CIM for DOD implementation. An 
extensive training effort is currently underway to educate 
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senior IS executives and functional managers, including the 

members of the CIM executive groups. 

IDEF also presents managers with choices that they would 
not even consider using other methods, including 
completely eliminating the process or activity, revamping 
procedures or the judicious application of information 
technology to help solve the problem. [Ref. 21: p. 10] 

Developed by the Army Corps of Engineers, IDEF is a process 

driven, planning methodology that provides a framework for 

building an IS architecture. 

The Navy is currently evaluating IDEF for use service¬ 
wide. The Naval Information Systems Management Center (NISMC) 
is evaluating seven IS project proposals submitted by the Navy 
IDEF Workgroup. These projects consist of information systems 
from various commands. NISMC will select prototype projects 
which will commence in April 1992 and must be scoped to ensure 
comp'letion in 120 days. These projects will determine the 
strengths and weaknesses of IDEF and ascertain if IDEF 
toolsets are user-friendly as well as the level of expertise 
required to use themi. The recommendations made to NISMC will 
be valuable in determining IDEF's future role within the Navy. 

3. Other Efforts 

As illustrated by IDEF, there is a concerted effort 
underway by the services to cooperate with the CIM initiative. 
Each service is feverishly working to develop or evaluate the 
one architecture that will become the standard. What must be 
understood is that there may not be "one" single methodology 
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that can be applied to each service or even to each department 
within the services. Sufficient room for interpretation must 
be allowed for the adaptation and manipulation of 
methodologies within specific organizational cultures. 
Another political barrier is the issue of ownership. Intra- 
and inter-service power plays can seriously hinder 
implementation. If one methodology produced by a service, 
major command or department, is forced on other agencies, the 
natural, human nature response of rivalry, resentment and 
resistance can hamper implementation, 
a. NAMO effort 

Several IS architecture efforts are currently 
underway in the Department of Navy. For NAVAIR, the Naval 
Aviation Maintenance Office (NAMO) has been chartered to 
develop a prototype Information Strategy Plan (ISP) and a Data 
Administration (Df.) Program for aviation logistics. This 
effort, initiated approximately one year ago, has been 
severely hindered by politics in the following ways: 


1. Scope: Broadly defined, the data collected for the DA 
program has grown exponentially. Difficulty now exist 
now in how to utilize all the information gathered. 

2. Personnel: There are only six members assigned to the 

NAMO project, none of whom is full time. Other 
activities have taken precedence over the ISP and DA 
resulting in a four month suspension until April 1992. 

3 . CIM: The requirements and directives for CIM frequently 
conflict with methods already in progress requiring 
IS/IRM divisions to be increasingly flexible. 
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4. Cooperation. Significant collaboration is required 
between NAMO, NAVAIR, and other DON agencies. Dissension 
has been expressed by others regarding NAMO's choice of 
methodology (James Martin's IE), case tool, and the scope 
of the project being too unique to aviation logistics. 
However, the NAMO team has received support from senior 
officials which enhances their credibility. 

Politics are inherent to the government and the military. 
Credibility, seniority and authority all profoundly affect 
political decisions. Moreover, with the high rate of turnover 
built into the services, what is important to one commanding 
officer 01 director may be superseded by the new goals and 
objectives of his/her relief or by those of a new boss. One 
senior official may envision IS architectures as critical, 
whereas another may determine the installation of a local area 
network (LAN) to be mission essential. Both deal with IRM 
issues, but if instituted imprudently, they can severely 
thwart projects already in progress. 

D. SENIOR MANAGEMENT INVOLVEMENT 

Underlying ail of the challenges to implementation is the 
degree of involvem.ent by senior officials. Senior management 
IS the catalyst for the entire effort. Top management must 
allocate sufficient resources, people, funding, necessary 
tools and hardware, for an IS architecture to be successfully 
imp 1ement ed. 

Senior management must ensure there is a balanced data 
administration (DA)/IRK strategy (Figure 11). The short- 
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term/tactical benefits must be assessed prior to addressing 
long-term/strategic projects. Data is standardized through 
the use of data dictionary tools, which then becomes the 
backbone for all architectures and maintenance support. 


STRATEGIC 

Deve1opment 

Re-engineering 


Support 

Attitudes 

TACTICAL 

Data 

Data 


Standards 

Connectivity 


DP ORIENTED BUSINESS 

ORIENTED 


Figure 11: A Balanced DA/IRy Strategy 

Frequently, data standards have been the primary focus of IRW 
plans resulting in a too limited scope. Here, data is coupled 
to business uses as end-users are given access to appropriate 
existing sources cr information (i.e., archives, files, 
screens, etc.) prirriarily supporting operation, but also 
decision support, areas. 

Once the tactical aspects are underway, the strategic 
elements can be satisfied. Development support is established 
for the construction of a data architecture. The redevelopment 
of standard interfaces and models is conducted based on the 
strategic needs of the organization. Also crucial in long¬ 
term planning is the re-engineering of organizational 
attitudes tcwurd the importance of information through 
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education and top-down planning. Again, the pressure for a 
paradigm shift must come from the top for success to be 
achieved. The balance between the tactical and strategic 
focus for DP and business issues provides valuable direction 
for senior management involvement in guaranteeing both short- 
and long-term success. 

The impact top management involvement has on IS 
development is illustrated in a survey conducted of thirty- 
three firms (Figure 12). While a relatively small sample, 
this survey suggests clear guidelines for success in IS 
devel opm.ent . Suggested levels of involvement by the senior 
official are depicted in Figure 13. Although not an accepted 
practice, it is critical that the senior executive insist on 
the development of a long-range IS plan and ensure it is 
ccnsister.t with o i gam t a 11 cn strategies. The senior 
official's involvement throughout the IS effort impresses upon 
both the implementors and the entire organization the 
importance ana pertinence of the picpect. 

Tw gain top rr.anagement support at the outset. NAVAIR's IRM 
division must make it clear that the purpose of the IS plan is 
tc dem.cnstrate to managemient that they understand the 
organization and possess- a sound basis for documenting and 
d<'velapi:ig information systeiris. [Ref. 6: p. 18j Fur t he r Ctor e , 
the team should point out that the IS architecture effort will 
r*-::.,'. : i. r :t':. ir.tended and um.ntended benefits to management. 
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Figure 12. Results of Application Development Survey [Ref. 
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CEO Involvement Levels [Ref. 





Intended benefits include: 


• Information is managed as a strategic corporate resource. 

• System priorities can be more comprehensively understood. 

• Functional redundancy can be identified. 

• Systems development will be more cost-effective. [Ref. 6: 
P. 17] 

Some additional benefits are: 

• Data administration functions are reviewed in order to 
capitalize on the benefits of data reusability ana shared 
integrated systems. 

• Healthy cross-education between users and MIS personnel 
may occur, indirectly reducing systems design errors. 

• Cooperation between different parts of the company that 
perform, sim,ilar function may increase. [Ref. 6: p. 17] 

An IS architecture provides a vehicle to manage data better 
and to develop more cost efficient, effective systems that add 
value to the orgamoation. The IRM division must impress on 
mianagement the realization that any improvements generated by 
the effort directly correspond to the organization achieving 
its business objectives. 

Senior management support is essential to implementation 
of an IS effort. Top managemient which is either too involved 
or too comiplacer.t can adversely affect implementation. They 
must be able to determiine what is best for the organization 
and its culture while complying with the existing political 
envir onment. 
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V. RECOMMENDATIONS 


The Naval Air Systems Command needs an organization-wide 
information systems architecture. The many architecture 
efforts which are currently in progress should be suspended 
and a comprehensive evaluation of IS/IRM accomplishments 
should be examined. Viable portions and/or successful 
projects should be selected for possible adaptation for a 
command-wide architecture. This suspension is critical for 
NAVAIR headquarter's to gain management control of information 
resources, as well as to enforce standardization throughout 
the organization. 

The IRM division, AIR-713, must evaluate Enterprise 
Architecture Planning to determine its feasibility as a 
methodology for the organization. It is recommended that 
initially consultants be retained to provide preliminary 
guidance and training. Once EAP has been officially accepted, 
preparatory training programs should be developed and 
instituted throughout the organization. To gain commitment 
and cooperation, training must begin with headquarters and 
senior management, and filter down. 

The pro 3 ect must conrunence as a top-down planning approach. 
It is vitally important to the success of this effort that the 
team include business and systems personnel and management and 
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users from field commands. This is essential for ownership to 
be gained at the outset. These persons are best identified 
during the initial training sessions. Understanding the 
vastness of NAVAIR, tele- and video-conferencing should be 
utilized whenever possible to minimize the impact on funding. 
Electronic mail (E-mail) can also serve to optimize currently 
available IT. 

As the team and project progress, the reorganization or 
redesignation of functional areas with NAVAIR will become 
apparent. The organization's culture must be accurately 
identified and planned for this to be successful. Again, 
outside consultants may be useful and worth the expense to 
ensure that strategy is developed correctly and satisfies the 
needs of the organization. 

EAP can be easily adapted to any requirements, 
methodology, or tools selected under CIM. IDEF corresponds 
well to level I and II of EAP. To gain the strategic 
advantage, however, the last two levels must be performed. 
The architecture and implementation phases confirm that data 
has been properly documented and that systems and applications 
created will meet organizational requirements and can be 
integrated. 

As DOD awaits CIM selection of a standard toolset, 
specifically I-CASE, it is not suggested that new tools be 
purchased. Several toolsets are already in use within NAVAIR. 
Texas Instrument's Information Engineering Facility (lEF) has 
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been widely used by NAVAIR and is recommended for continuation 
until the standard tool is promulgated. lEF is a fully 
integrated CASE product that supports the entire life cycle. 
The current lEF environment is included in Appendix A. 
Upgrades to existing software are more economically feasible 
at this time. 

The use of Enterprise Architecture Planning and the tools 
and resources currently available will enable NAVAIR to 
achieve the long-term goals of improved productivity, 
efficiency, effectiveness and quality while reducing costs. 
The decision making process will be greatly enhanced providing 
better utilization of resources. EAP will allow NAVAIR to 
adapt quickly to the rapidly changing CIM environment. 

The savings promised by CIM are overestimated. The 
developnient of an IS architecture, the consolidation of 
systems and departments, coupled with the reduction of 
personnel, will require significant up-front dollars and 
resources. However, the CIM mandate is permanent. NAVAIR 
must work to adhere to its precepts and directives to ensure 
that reductions in resources do not adversely affect the 
organization's military mission. A comprehensive, command¬ 
wide information systems architecture will provide the best 
mechanism for achieving that objective. 
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A. FOLLOW-ON STUDY AREAS 


The following is a list of areas which would be beneficial 
in assisting NAVAIR with an IS architecture: 

• A case study of one or more organizations, non-profit 
and/or of similar size, which have successfully completed 
and implemented an information systems architecture. 

• A case study of the organizational culture of NAVAIR. This 
would be of great importance to the IS effort as well as 
save considerable time. 

• Provide overviews of tools chosen and supply critical 
cost/benefit analysis for systems and technology. 

The Naval Air Systems Command IRM division is actively 
pursuing solutions to its information systems architecture 
requirements. High-level discussions are in progress to 
evaluate viable options. Several significant architecture 
pro]ects are underway but are of limited scope. NAVAIR must 
develop a commar.o-wide architecture to identify and eliminate 
redundancy and tc produce more cost-effective systems that 
meet the needs of the organization. The proposed 

compiehens1ve effort will prov:de NAVAIR with a strategic 
advantage in an era of diminishing resources. 
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APPENDIX A 


[Ref. 23: p. 6] 

Texas Instrument's lEF Environment for DP/MIS Applications 

A. Life Cycle Phases Supported: 

1. Program Management 

2. Method Management 

3. Strategic Systems Planning 

4. Analysis 

5. Design 

6. Cede (Application) Generator 

7. Configuation Management 
S. Reverse/Re-Engineering 

B. Methods Supported: 

1. Information Engineering 

C. Languages Supported for Applications: 

1 . C o b 0 1 

D. DBMS Supported for Application: 

1 . DE2 

E. P1 atforms/Operating Systems for Development: 

1. IBM MVS 

: . TSO 

3. ISPF 

4. T: Bus Fro 
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5. IBM PS/2 


» 6. PC-AT 

F. Price: 

1. approx. $200K + 

G. Representative Data Dictionary/Repository Tools: 

1. Integrated main-frame based repository. 

2. Supports IBM's Repository Manager. 

H. Future Phase and Method Support: 

1. Ada Code Generator 

2. Object Oriented Analysis 

3. Open Application Systems 
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